The Object Management Group (OMG) consortium has defined an architecture termed Common Object Request Broker Architecture (CORBA). The CORBA architecture enables the distribution of applications on different kinds of platforms. According to the client-server model, there are two kinds of applications: the client applications that request services and the server applications that offer the requested services.
In CORBA architecture the services and computer units work together so that the services are independent of the operating systems and the hardware platforms. CORBA encapsulates the C++ code and data into objects so that the objects are accessible by means of method invocations. In this way a client can access objects located in another computer unit. The client does not know where the service takes place geographically, but only the name and interface of the objects providing the service.
CORBA 2.0 includes specifications for a functionality that is termed Object Request Broker (ORB). ORB enables transparent communication between applications. The client and the server applications are separated from the mechanism used for communicating, activating, and storing objects. Each computer unit which needs to communicate with other units has the ORB functionality.
Intelligent Network (IN) is an architectural concept for the creation and provision of advanced telecommunications services.
FIG. 1 shows an example of IN architecture based on CORBA. The SS7 network can communicate with the Public Switched Telephone Networks (PSTNs) and the Public Land Mobile Networks (PLMNs). It can also communicate with CORBA through a bridge shown in FIG. 1. Furthermore, the SS7 network can communicate with the Internet via CORBA.
The International Telecommunication Union (ITU) has defined a protocol named the Transaction Capabilities Application Part (TCAP). TCAP describes dialog handling and communication procedures for the transfer of non-circuit-related signals. TCAP is a general protocol that reduces the need for the development of new protocols when new features are introduced in the SS7 network. TCAP belongs to layer 7 of the OSI model and provides a protocol layer for specific applications such as mobile and IN applications.
For example, the Intelligent Network Application Protocol (INAP) is one protocol that TCAP supports. INAP relates to communication between IN physical network elements. INAP is defined by ITU, and the other version of INAP called “Core INAP” is defined by ETSI (European Telecommunication Standards Institute).
Mobile Application Part (MAP) is another protocol that TCAP supports. MAP is used in mobile networks.
INAP and MAP are SS7 network protocols. The commonly known TCP/IP protocol is one of the Internet protocols.
The next three protocols are used in CORBA:
General Inter-ORB Protocol (GIOP) specifies standard transfer syntax and a set of message formats for communications between the ORBs.
Environment-Specific Inter-ORB Protocol (ESIOP) specifies how GIOP messages are exchanged using a particular networking or distributed computing infrastructure.
Internet Inter-ORB Protocol (IIOP) specifies how the GIOP messages are exchanged using TCP/IP connections. IIOP provides interoperation between ORBs on the vendor-neutral transport layer.
Light Directory Access Protocol (LDAP) specifies directory models supporting X.500 directory models, while avoiding certain resource requirements of X.500 Directory Access Protocol (DAP). The X.500 directory models and said DAP are defined by ETSI. LDAP is specifically targeted at Internet management applications and browser applications that provide read access or write access to directories. LDAP assumes there are one or more servers providing access to the tree making up the entries. Each entry has a name formed from letters and numbers representing attribute values so that one or more attribute values at the beginning of the name distributes the entry form to all others. The tree being made up of the entries is termed an LDAP directory.
Besides protocols also abstract languages and special transfer syntaxes are needed. The abstract languages and transfer syntaxes define how the data are to be encoded and located in the messages.
Interface Definition Language (IDL) is an abstract language used in CORBA. IDL specifies objects that compose an interface of a client application.
Common Data Representation (CDR) is a transfer syntax that maps IDL types, i.e. data types, to low-level representation for on-wire-transfer between ORBs.
The SS7 network delivers messages that are specified using data structure language named the Abstract Syntax Notation One (ASN.1). The ASN.1 language is capable of specifying complex recursive data types and is used to describe the content and context of messages. During transfers over the SS7 network, the values of the ASN.1 types are encoded according to a transfer syntax such as Basic Encoding Rules (BER). The BER enables a series of recursive elements, comprised of Tag, Length, and data fields. The Tag fields indicate what type of data is packed into the message, and the Length fields indicate the number of bytes of data within this particular part of the message.
In order to convert data between different networks, certain kinds of mapping rules are also needed. The Telecom Task Force group in OMG has defined the mapping rules between INAP and IDL data definitions. In addition, the X/open Preliminary Specifications include an ASN.1 to IDL translation algorithm. The INAP/MAP messages of the SS7 network are inputs for generating the GIOP messages of CORBA, and vice versa. This message generation is executed according to the mapping rules.
The Service Logic Environment (SLE) is an entity made for executing CORBA services. The SLE is equipped with an ORB functionality, which enables applications to provide services for other applications.
As illustrated in FIG. 2, the SLEs connect the applications to CORBA. An Inter-Working Unit (IWU), shown in FIG. 2, is one part of the bridge, shown in FIG. 1, which connects the CORBA network to the SS7 network. In this context, IWU refers to a process, not necessarily to a computer unit. IWU is equipped with the ORB functionality as well as the SLEs. Therefore, IWU and the SLEs comply with GIOP, ESIOP, and IIOP protocols. IWU communicates with the SLEs via CORBA using GIOP messages.
TCAP is a protocol as described above. In this paper, TCAP also refers to a process. As shown in FIG. 2, TCAP is the other part of the bridge connecting CORBA and the SS7 network. TCAP communicates with the SS7 network using INAP or MAP messages.
The bridge receives GIOP messages from an SLE, and INAP/MAP messages from the SS7 network. Receiving a message can be termed an event. The bridge creates a record of an event, which record includes data received in a message. Inside the bridge, IWU and TCAP may communicate with each other by transmitting records of events.
A dialog refers to communication between two applications using data conversions. A dialog is composed of dialog primitives. The dialog primitives indicate the beginning of a dialog, the formation of a dialog, the continuation of a dialog, and the end of a dialog. The dialog primitives may also transmit data belonging to a dialog.
When a TCAP begin message is received from the SS7 network to the bridge, an association is formed between an application executing in SLE and the SS7 layer in the bridge. This TCAP begin message is termed SS7Begin dialog primitive. Alternatively, the SLE can initiate the association between it and the SS7 layer in the bridge by sending an SLEBegin named dialog primitive. The association represents a dialog which has been established all the way from the SLE application to the application on the SS7 network. Events relating to one association compose a dialog. The application on the SS7 network may be, for example, a call instance process executing in a service switching point (SSP). The dialog could represent, for example, an IN control relationship between the SLE application and the SSP call instance.
During an association, i.e. during a dialog, a CORBA application may execute remote operations for an SS7 application. The Remote Operation Procedure (ROP) defines how the remote operations are invoked and how the results or errors of the invoked remote operations are received. The ITU has defined remote operations for CORBA. These remote operations are called IDL operations.
The ITU has also classified different kinds of INAP operations. The INAP operations define how remote operations of SS7 applications are invoked and how the results or errors of the invoked operations are received.
The Telecom Task Force group in OMG has defined mapping rules between the IDL and the INAP operations. The mapping rules are needed because CORBA applications and SS7 applications should be able to execute remote operations for each other.
In data conversions the data of a first format is converted to the data of a second format. The data of the first format as well as the data of the second format is stored in one or more data structures. A utility is a program or a part of a program which executes data conversion between certain data structures. Utilities compose a set which is termed a utility set. Correspondingly, messages of a certain protocol compose a message set. For example, the messages of the INAP protocol compose an INAP message set.
The utilities perform conversions from one encoding format to another. In this case encoding means, for example, how data structures are represented in the data communication between two entities. The aim is to provide conception of the structure and semantics of the data on the target side which is similar to the source side.
The present invention relates generally to the bridge shown above. Next, the object-oriented programming and compiler techniques utilized within the bridge will be discussed.
JAVA and C++ are examples of object-oriented programming languages. The objects may compose, for example, an interface of a CORBA server application. Each object is defined as a class, which includes some data and methods for handling that data. A class may also include methods for handling the data of other classes.
A compiler is a program that reads one or more input files and writes an executable code, or a source code, in one or more output files. The executable code may act, for example, as a utility set offering conversions between different data definitions. A compiler itself, and the files read and processed by the compiler, may include various classes.
More specifically, the invention concerns converting BER encoded ASN.1 data structures into the CDR data structures, and vice versa. The BER encoded ASN.1 data structures are named briefly as BER data structures and said conversions are named briefly as BER-CDR conversions. The BER-CDR conversions are executed in the IWU shown in FIG. 2.
Each utility can execute the BER-CDR conversion between an IDL-based interface definition and an ASN.1-based interface definition. There could be several versions of both types of interfaces. Thus a utility executes the conversion between a certain version of the interface defined by the IDL and a certain version of the interface defined by the ASN.1.
The interfaces could correspond to, for example, a certain MAP, INAP, or CAP version and their interface which is based on ASN.1 or IDL definitions. For instance, a utility could perform a conversion related to CAP (Camel Application Protocol). It could perform the conversion between the CDR encoding of a data type in the IDL interface and the BER encoding of a data type in the ASN.1 interface for CAP version 3.
There are older and newer versions of INAP/MAP message sets. Each utility can execute the BER-CDR conversion between a data structure of a certain GIOP message version and a data structure of a certain INAP/MAP message version. Thus, a great many utilities for the BER-CDR conversions are needed to enable conversions between each GIOP and INAP/MAP message set versions.
Snacc is an example of a known freeware compiler which can be utilized in the BER-CDR conversions. As any compiler, the Snacc comprises at least the lexical analyzer, grammatical parser, and code generator. The lexical analyzer extracts grammatical tokens from the input stream. In this case, the input stream contains BER encoded ASN.1 data structures.
The Snacc compiler uses its embedded BER library for generating a C++ code. The BER library has the functionality to convert BER data structures into ASN.1 C++ classes, and vice versa.
The Snacc compiler generates the C++ code for BER-CDR conversions. The C++ code includes the following method calls of the BER library:                BEncPdu        BDecPdu        BEnc        BDec        BEncContent        BDecContent        
In these method names “Enc” refers to encoding and “Dec” refers to decoding. “Pdu” refers to a Protocol Data Unit; which is a block of data transmitted in the network.
The procedure hierarchy structure of the generated code corresponds to the structure of the ASN.1 data types presented as input to the Snacc compiler. Thus, depending on how the data types have been nested, the encoding routines of different data types call each other. For example, if datatype1 contains datatype2 in its structure, the encoding function of datatype1 calls the encoding function of datatype2.
Every C++ class generated is derived from a base class named AsnType. The code generation is executed one data structure at a time and one field of the data structure at a time.
For example, if the type of the field is integer, a class named AsnInt is used. Thus, the type of the field determines which derived class of the AsnType base class is used in the code generation.
The Orbix library (produced by a company named IONA) is an example of a known tool which can be utilized in the BER-CDR conversions. The Orbix library uses its embedded CDR library for generating C++ code.
The CDR library has a functionality to convert CDR data structures into IDL C++ classes, and vice versa.
FIG. 3A shows how the utilities for the BER-CDR conversions are generated in prior art. The generation of the utilities consists of at least three phases that are marked 1 to 3. The second phase is further divided into three sub-phases 2A, 2B, and 2C.
Thus the Snacc compiler can be used to generate the C++ code for phase 1, in which BER encoded data structures are converted to ASN.1 classes or vice versa. Correspondingly, the Orbix library can be used to generate the C++ code for phase 3, in which IDL C++ classes are converted to CDR encoded data structures or vice versa.
In prior art, there is no tool for phase 2, i.e. the translation phase. Therefore a programmer has to write: a) a program “2A” for translations between the ASN.1 C++ classes and ASN.1 instances, b) a program “2B” for translations between the ASN.1 instances and IDL instances, and c) a program “2C” for translations between the IDL instances and IDL C++ classes.
The following example describes what kind of definition files the NAC compiler reads. The example concerns an “InitialDP” named operation which is defined in “IN Capability Set 1”.
The definition for the “InitialDP” operation may be in a file named “operation.asn”:
CS1OPErationTypes DEFINITIONS ::=...InitialDP::= OPERATIONARGUMENT  InitialDPArgERRORS {...}InitialDPOPE ::= OBJECT {&ArgInitialDPArg&Err{...}
The definition for an “InitialDPArg”, which is printed in the “operation.asn” file, is given in another file that may be named “argument.asn”. The definition for the “InitialDPArg” is given in an “argument.asn” file as:
InitialDPArg ::= SEQUENCE {serviceKey[0] ServiceKey,...redirectionInformation[30] RedirectionInformation...}
The following two examples concern the conversion of the “InitialDpArg” named data structure which is showed above, and which is BER encoded. We may assume that also the corresponding CDR data structure is named the “InitialDpArg”.
The Snacc compiler processes the data structure field by field. This processing depends on the type of field. For example, “InitialDpArg” data structure contains a field which is named a “serviceKey”. When the Snacc compiler has read the “serviceKey” field, the Snacc compiler generates C++ code so that the BDecContent method of the AsnInt class is called because the “serviceKey” field is the integer type.
The C++ code processing also depends on whether a field includes a data structure or not, i.e. on whether the processed data structure is nested or not. If the field of the data structure includes a data structure, the data structure included is handled in the same way as the field itself.